-
Notifications
You must be signed in to change notification settings - Fork 159
Adding support for static arrays #666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
Thanks for the PR! It might work :) I'll be shocked if it's that simple, but maybe :) Could you add a test to |
Looks like I didn't solve the problem in its entirety, but I think I got a useful subset of it. |
Looks like a couple of tests failed, but I think they are tests that are trying to ensure arrays generate a suitable descriptive error message, so perhaps those tests can be amended to actually work properly? |
@adetaylor do we just make sure that they build? is there actually a way to pass a |
I hadn't actually looked at the two failing tests. I assumed they directly involved arrays, given their names, but apparently not. I'm not sure what's going on here. My guess is that I will be happy to take a proper look but it might take me a few days. I'd really like to land your PR, so I'll definitely get there in the end. Apologies if it takes a while! The first thing I'll do is to run these tests with the debugging variables mentioned here and see if I can see what |
Yep, bindgen generated mod bindgen { /* automatically generated by rust-bindgen 0.59.4 */
#[allow(non_snake_case, non_camel_case_types, non_upper_case_globals)]
pub mod root {
#[allow(unused_imports)]
use self::super::root;
pub mod std {
#[allow(unused_imports)]
use self::super::super::root;
}
pub mod __gnu_cxx {
#[allow(unused_imports)]
use self::super::super::root;
}
pub type __uint32_t = ::std::os::raw::c_uint;
extern "C" {
#[link_name = "\u{1}_Z9take_funcSt8functionIFbjEE"]
pub fn take_func(arg1: [u64; 4usize]);
}
}
} Whoever wrote this test must be aware that |
Yes, it was I that added those tests, I guess because I saw this oddness spat out of bindgen :) I'd like to work out if we can get to a point where genuine arrays are supported, but we continue to generate errors in cases like My next steps would be:
|
I see. Is it possible to make |
Unfortunately it's very common to encounter stuff like this in the C++ STL headers, so if bindgen panicked then most autocxx use-cases wouldn't work. bindgen needs to successfully output something then autocxx needs to mark it as unsupported. |
There are some types which bindgen cannot understand. It instead uses an array in their stead. Previously, autocxx did not understand arrays and therefore these types were rejected by autocxx, and substituted for the correct error message. With #666, we're trying to support actual arrays in autocxx, and thus we need to disambiguate real arrays from these opaque types. This change does just that. It relies on autocxx-bindgen emitting additional annotations.
I made a bit of progress here. This branch of autocxx-bindgen adds an annotation to opaque types: adetaylor/rust-bindgen@master...adetaylor:opaque-annotation In the output of bindgen, which autocxx parses, we now see something like this in case it's not a real array, but is instead an opaque type: extern "C" {
#[bindgen_arg_type_opaque(arg1)] // this bit is new
#[link_name = "\u{1}__Z9take_funcNSt3__18functionIFbjEEE"]
pub fn take_func(arg1: [u128; 3usize]);
} This can then be spotted and used by So that's the basic outline of what we need to do. It works. But a bit more work is required before we can merge this:
|
(If you want to make progress on any of this, that would be terrific! If you want to tell autocxx to use a custom check out of autocxx-bindgen, just uncomment the (relevant bits of) the |
Fantastic! I will try to have a go at this when I find some time. Hopefully this week. |
I've taken your commits here into a new PR, #969, so I can fix some of the problems that show up. The good news is that subsequent work has adjusted autocxx-bindgen so it nowadays does distinguish opaque types. So it should be possible to land this somewhat soon, but there are still some test failures to look into. |
Fixes #266?
I got
Encountered type not yet known by autocxx: [ std::os::raw::c_char; 8usize ]
in generated code. Not sure if it's the same issue.I hacked this PR to get my use case to work, I don't know if I am missing some important cases.